Active execution tracing visualization

ABSTRACT

Visualization for active execution tracing pertains an interface used to view, analyze, and manipulate data relating to events leading to a point-of-failure during execution of a function or at least a portion of an application, program, process, or other assemblage of programmable and executable code.

DESCRIPTION OF THE DRAWINGS

Active execution tracing and visualization thereof are described hereinwith reference to the following figures.

FIG. 1 shows devices communicating over a network, with the devicesimplementing example technologies for active execution tracing andvisualization thereof.

FIG. 2 shows an example of system components utilized to implementexample technologies for active execution tracing and visualizationthereof.

FIG. 3 shows a more detailed implementation of an example componentdescribed from FIG. 2.

FIG. 4 shows an example processing flow in accordance with at least oneimplementation of active execution tracing and visualization thereof.

FIG. 5 shows an interface in accordance with an example implementationof active execution tracing visualization.

FIG. 6 shows an example processing flow for implementing activeexecution tracing visualization.

DETAILED DESCRIPTION

Active execution tracing and visualization thereof are described herein.More particularly, the description herein pertains to tools, services,and corresponding interfaces used to capture, analyze, and interact withevents leading to a point-of-failure during execution of a function orsome other portion of an application, program, process, or otherassemblage of programmable and executable code.

FIG. 1 shows example network environment 100 in which active executiontracing and visualization thereof may be implemented. However,implementation of active execution tracing and visualization thereof,according to at least one example, is not limited to networkenvironments. Regardless, in FIG. 1, client device 105, server device110, and “other” device 115 may be communicatively coupled to oneanother via network 125; and, further, at least one of client device105, server device 110, and “other” device 115 may be capable ofimplementing active execution tracing and visualization thereof 120, asdescribed herein.

Client device 105 may be at least one of a variety of conventionalcomputing devices, including a desktop personal computer (PC),workstation, mainframe computer, Internet appliance, set-top box, andgaming console. Further, client device 105 may be at least one of anydevice that is capable of being associated with network 125 by a wiredand/or wireless link, including a personal digital assistant (PDA),laptop computer, cellular telephone, etc. Further still, client device105 may represent the client devices described above in variousquantities and/or combinations thereof. “Other” device 115 may also beembodied by any of the above examples of client device 105.

Server device 110 may provide any of a variety of data and/orfunctionality to client device 105 or “other” device 115 in accordancewith at least one implementation of active execution tracing andvisualization thereof 120. The data may be publicly available oralternatively restricted, e.g., restricted to only certain users or onlyif an appropriate subscription or licensing fee is paid. Server device110 may be at least one of a network server, an application server, aweb blade server, or any combination thereof. Typically, server device110 is any device that may be a content source, and client device 105 isany device that may receive such content either via network 125 or in anoff-line manner. However, according to the example implementationsdescribed herein, client device 105 and server device 110 mayinterchangeably be a sending node or a receiving node in networkenvironment 100. “Other” device 115 may also be embodied by any of theabove examples of server device 110.

“Other” device 115 may be any further device that is capable ofimplementing active execution tracing and visualization thereof 120according to one or more of the examples described herein. That is,“other” device 115 may be any software-enabled computing or processingdevice that is capable of implementing active execution tracing, andprovide visualization thereof, for at least a function, process, or anyother portion of an application, program, or other assemblage ofprogrammable and executable code in any one of an operating system, amanaged execution environment, and a testing environment. Thus, “other”device 115 may be a computing or processing device having at least oneof an operating system, an interpreter, converter, compiler, or runtimeexecution environment implemented thereon. These examples are notintended to be limiting in any way, and therefore should not beconstrued in that manner.

Network 125 may represent any of a variety of conventional networktopologies and types, which may include wired and/or wireless networks.Network 102 may further utilize any of a variety of conventional networkprotocols, including public and/or proprietary protocols. Network 125may include, for example, the Internet as well at least portions of oneor more local area networks (also referred to, individually, as a“LAN”), such as 802.11 system; a personal area network (i.e., PAN), suchas Bluetooth.

FIG. 2 shows system 200 having components utilized to implement at leastone example of active execution tracing.

Component A 205 and component B 210 may represent a function, process,or any other portion of an application, program, or other assemblage ofprogrammable and executable code that may receive an instruction toenter into execution and a subsequent instruction to exit fromexecution.

Write buffer 215 may represent a buffer to write data associated with atleast one of component A 205 and component B 210 into a tracing service.When data is first written to write buffer 215 from at least one ofcomponent A 205 and component B 210, active execution tracing may beinitialized. Upon such occurrence, write buffer 215 may interface withtracing service 220 to receive a pointer to logging buffer 225.

The data written into write buffer 215 from at least one of component A205 and component B 210 may include an instruction, or at least a datarepresentation thereof, for a respective one of the components to enterinto execution; at least one frame of a stack trace including, e.g.,data indicating the source of an instruction to enter into execution(i.e., a return address); an actual instruction (e.g., callback method)passed to the respective component; the time that an instruction ispassed to the respective component; the name of the respectivecomponent, etc.; and an instruction for the respective component to exitfrom execution. A stack trace may refer to a sequence of frames on acall stack, which may refer to a reserved amount of memory that tracks asequence of methods called in an application or program, for arespective one of component A 205 and component B 210. Moreparticularly, a stack trace may refer to a reserved amount of memorythat tracks a sequence of functions, methods, or other portions ofexecutable code called in an application or program. Each frame of acall stack may refer to at least one of a function, method, routine,instruction pointer, and register value that have been pushed on thecall stack.

Alternative implementations may contemplate write buffer 215 furtherreferring or pointing to source code, or at least data related to thesource code, from at least one of component A 205 and component B 210.The source code, or data related thereto, may provide a more in-depthview of a, e.g., stack trace that is detected by or stored to tracingservice 220. The data related to the source code may include, e.g., anentered function, a module to which the entered function corresponds,etc. Even further alternative implementations may then connect such datato source code for analysis.

Accordingly, at least one example implementation of active executiontracing 120 may track modules, including DLLs (dynamic link libraries)and EXEs (executable files), as well as signatures used in anapplication or program to which either of component A 205 and componentB 210 correspond. Such tracking may occur in parallel with at least oneof a call to enter execution and a call to exit execution for acorresponding function.

Write buffer 215, after initialization of tracing service 200, may writethe data (i.e., stack trace, etc.) from the respective one of componentA 205 and component B 210 into logging buffer 225 corresponding totracing service 220.

Tracing service 220 may refer to a service that is utilized to captureand analyze events leading to a point-of-failure during execution of afunction, process, or other portion of an application, program, process,or other assemblage of programmable and executable code.

Tracing service 220 may be a stand-alone service or, alternatively, maybe associated with a debugger or other testing tool. Further, tracingservice 200 may be disposed within any one of an operating system, amanaged execution environment, and a testing environment. Even further,at least one alternative implementation of tracing service 220 mayincorporate write buffer 215 therein.

Logging buffer 225 may refer to a buffer disposed within, or otherwiseassociated with, tracing service 220.

Logging buffer 225 may be a rewriteable buffer having fields (i.e.,entries) that may be overwritten in predetermined cycles of timedependent upon predetermined conditions. For example, a respective fieldwithin logging buffer 225 may be overwritten with newly received datafrom either of component A 205 and component B 210 if the respectivefield has stored therein at least the instruction for the correspondingcomponent to enter into execution and the instruction for the componentto exit from execution. By this example implementation, a stack traceand other data pertaining to a particular one of component A 205 andcomponent B 210 may be retained, and therefore traced, until therespective component has exited from execution. The length of theoverwriting cycles and the conditions under which fields of loggingbuffer 225 may be overwritten may vary from one implementation toanother, and therefore the example provided above should not beconsidered to be limiting in any manner. That is, alternativeimplementations of active execution tracing 120 may contemplate loggingbuffer 225 as being expandable, and therefore the aforementionedoverwriting may be rendered moot.

Further still, according to at least one implementation of activeexecution tracing 120, at least portions of data buffered within loggingbuffer 225 may be committed to one or more persistent storages, whichmay be a local storage or located on at least one other of devices 105,110, and 115 on network 125 (see FIG. 1). The commitment of at leastportions of logging buffer 225 to a more persistent storage may beimplemented upon occurrence of an event with regard to the applicationor program to which component that writes data to logging buffer 225correspond. For example, when write buffer 215 writes data fromcomponent A 205 into logging buffer 225 and a crash occurs duringexecution of an application or program to which component A 205corresponds, at least portions of logging buffer 225 containing datarelated to component A 205 may be committed to a persistent storage. Thedata on the one or more persistent storages may then be studied andanalyzed for various purposes. Alternative events that may cause orotherwise initiate at least portions of logging buffer 225 to becommitted to one or more persistent storages include a user command orautomated query made to determine the processing status of a particularcomponent or even the application or program to which the particularcomponent corresponds. Such user queries to tracing service 220 may bemade via a user interface, examples of which are described furtherbelow.

Alternative implementations of tracing service 220 may contemplatelogging buffer 225 being provided as part of a “per-process” or“per-application/program” basis, either incorporated as part of tracingservice 220 or separate from the service. Regardless, in suchalternative implementations, logging buffer 225 may receive stack tracesand other data from components corresponding to individual applicationsor programs, and be linked to other such implementations of loggingbuffer 225 corresponding to other individual applications or programs toprovide a more comprehensive view of processing of related applicationsor programs upon an occurrence of one of the aforementioned events.

As stated above, the data on the one or more persistent storages maythen be studied and analyzed for various purposes. For example, if acrash occurs within an application to which one of the aforementionedcomponents, processes, or programs correspond, the data committed to thepersistent storage may be transmitted to, or otherwise accessed by, aprogramming source or proprietor of the application for analysis of thecause of the crash. That is, the data committed to the persistentstorage may prove to be helpful in a crash analysis and, consequently,the improvement of the execution of corresponding code.

FIG. 3 shows an example of a detailed implementation of logging buffer225 shown in FIG. 2. The components within logging buffer 225 arebuffered chronologically. However, the display of such components, andrelated data, may be ordered in a customized manner (i.e., according toeither time or component or function), as desired for analysis.

According to one example implementation of logging buffer 225, columns305, 310, 315, 320, 325, and 330 may represent consecutive timeincrements during the processing of an application or program havingcomponents A, B, C, D, E, and F. In that case, the respective columns305, 310, 315, 320, 325, and 330 may contain at least one of: aninstruction for the respective one of components A, B, C, D, E, and F toenter into execution; at least one of a stack trace (e.g., 305′, 310′,315′, 320′, 325′, and 330′) as well as a return address, a callbackmethod, the time that the instruction to enter into execution is passedto the respective component, the name of the respective component,function arguments, etc.; and an instruction (e.g., 305″, 310″, 315″,320″, 325″, and 330″) to exit from execution.

As alluded to above, logging buffer 225 may further point to sourcecode, or data related thereto, from at least one component writtentherein. Therefore the respective sub-fields within the example of FIG.3 may provide a pointer, link, or even annotation of such source codevia a user interface.

Another example implementation of logging buffer 225 may be organized bythe chronological ordering of the respective instructions for therespective components A-F to enter into execution. Thus, each sub-field(e.g., 305′, 310′, 315′, 320′, 325′, and 330′; and 305″, 310″, 315″,320″, 325″, and 330″) may be individually time-stamped to indicate thetime at which the corresponding data was written into logging buffer225, particularly since the data within each sub-field may not bereceived in the same chronological order as the correspondinginstruction to enter into execution.

Each column (alternatively referred to as buffer space, buffer entry, orbuffer field), corresponding to a respective one of components A-F, mayrefer to one field of a call stack. Thus, each column of logging buffer225 may include sub-fields to receive at least a combination of theinstruction to enter into execution and the instruction to exit fromexecution. Accordingly, if a respective one of columns 305, 310, 315,320, 325, and 330 of logging buffer 225 in FIG. 3 contains both aninstruction to enter into execution and an instruction to exit fromexecution, it may be presumed that the corresponding function hascompleted execution and thus the respective column of logging buffer 225may be overwritten for a subsequently called component.

Implementations to provide a visualization of logging buffer 225 may beorganized primarily by component, rather than chronological time. Forexample, a visualization of components A-F may show the elements of acall stack buffered in logging buffer 225 based on order of dependencytherebetween. The respective columns 305, 310, 315, 320, 325, and 330may then have sub-fields to receive a combination of the instruction toenter into execution and the instruction to exit from execution, whichare respectively time-stamped.

Regardless, the above descriptions of logging buffer 225 are provided asexamples only and are not intended to be limiting in any manner.

FIG. 4 shows example processing flow 400 for at least one implementationof active execution tracing 120 (see FIG. 1). Processing flow 400 isdescribed below with references to features from FIGS. 1-3, particularlysystem 200 of FIG. 2, although such implementations are provided only asexamples and are not intended to be construed in any limiting manner.

Block 405 may refer to write buffer 215, which may be external to orincorporated within tracing service 220, detecting a call (e.g., afunction call) from at least one of component A 205 and component B 210to enter into execution. Block 405 may further refer to write buffer 215receiving from at least one of component A 205 and component B 210 astack trace as well as other data from a respective one of thecomponents including, e.g., a return address, a callback method, thetime that an instruction is passed to the respective component, the nameof the respective component, etc.; and writing the same to loggingbuffer 225.

If a call to enter into execution from either of component A 205 andcomponent B 210 is detected by write buffer 215 for the first time,block 405 may further include a verification and initialization process.The verification may include write buffer 215, in conjunction withtracing service 220, verifying that the calling component is to betraced by tracing service 220. The initialization process may includewrite buffer 215 subsequently interfacing with tracing service 220 toreceive at least a pointer to logging buffer 225, which may beassociated with tracing service 220.

Block 410 may refer to logging buffer 225, which may be incorporatedwithin tracing service 220 or external thereto, buffering data receivedfrom write buffer 215 in any manner described above with regard to FIG.3. Such data may include the call to enter into execution for arespective one of component A 205 and component B 210, a stack trace orother data from a respective one of component A 205 and component B 210including, e.g., a return address, a callback method, the time that aninstruction is passed to the respective component, the name of therespective component, etc.

Decision 415 may refer to detection of an event that may determinewhether at least portions of logging buffer 425 are to be committed to apersistent storage. Decision 420 may be made by write buffer 215 or,alternatively, another component associated with tracing service 220.Examples of an event detected during decision 420 may include a crash(i.e., abnormal end) of an application or program to which a respectiveone of component A 205 and component B 210 correspond, a user command,an automated query, or an implementation of a debugging process.

Subsequent to either of block 405 and block 410 or subsequent tonegative decision 415, write buffer 215 may detect a call to exitexecution from at least one of component A 205 and component B 210. Thecall to exit execution may typically be buffered in logging buffer 225.Alternative implementations of processing flow 400 may even foregobuffering the detected call to exit execution. Regardless, havingdetected a call to exit execution for a respective one of component A205 and component B 210, a field within logging buffer 225 that storesall detected and buffered data regarding the respective one of componentA 205 and component B 210 may be overwritten in accordance with acorresponding buffering cycle.

Negative decision 415 may return processing flow 400 to block 405 forfurther tracing of called components.

Block 420 may refer to, subsequent to positive decision 415, at leastportions of logging buffer 225 being committed to a persistent storagefor purposes that may include, e.g., display, analysis, and study. Thepersistent storage may be local on a device upon which the correspondingapplication or program is or was running, the persistent storage may benetwork-based disposed on one or more devices, or the persistent storagemay be an off-line storage medium such as a disk or chip.

According to at least one implementation of active execution tracing120, subsequent to block 420, the data committed to the persistentstorage may be utilized for, e.g., crash analysis. Such analysis may bemade after a network-based transmission of the data to a programmingsource or proprietor of the application or program to which at least oneof the buffered components correspond. Alternative, such analysis may beexecuted locally, upon the device which the corresponding application orprogram is or was running.

FIG. 5 shows example interface 500 that serves as an exampleimplementation of active execution tracing visualization. Interface 500is described below with references to features from FIGS. 1-4,particularly system 200 of FIG. 2, although such implementations areprovided only as examples and are not intended to be limited in anymanner.

According to at least one example implementation of active executiontracing visualization, interface 500 may include a series of data fieldsin which data stored in one or more stand-alone or linkedimplementations of logging buffer 225 may be presented for visualexamination and interactive scrutiny. The data stored in the one or moreimplementations of logging buffer 225 may include myriad of combinationsof an instruction for a component to enter into execution, acorresponding stack trace, a return address, a callback method, the timethat an instruction is passed to the respective component, the name ofthe respective component, an instruction for the component to exit fromexecution, etc. Further, the data may be presented in such a manner thatdenotes the time at which data corresponding to a respective componentis detected and/or stored by tracing service 220 or pushed on acorresponding stack. Such notation may be made by, e.g., charting thedata against a time line or by affixing a time stamp to respective onesof the data fields.

Interface 500 may include times T1, T2, T3, and T4 along time axis 505;and further includes fields and sub-fields for displaying, relative toan appropriate time, data stored in the one or more linkedimplementations of logging buffer 225. The fields for the displaying thedata may be annotated along axis 510. Example interface 500 showshorizontal time axis 505 displayed orthogonally to axis 510, but thisimplementation is provided only as an example. Alternativeimplementations may vary the orientation of the axis or eliminate one ormore of the axis altogether. An example of such an implementation mayinclude a listing of data detected by write buffer 215 or tracingservice 220, stored in logging buffer 225, or alternatively pushed ontoa corresponding stack, with a time stamp affixed to corresponding data.

Interface 500 may show components A, B, C, and D listed vertically.Thus, data corresponding to the respective components may be displayedin the sub-field that corresponds to the time at which the respectivedata was detected by write buffer 215 or tracing service 220, stored inlogging buffer 225, or alternatively pushed onto a corresponding stack.Such components may be displayed as a result of a user-entered searchcriteria or, alternatively, as at least a part of default searchcriteria to be displayed.

Magnified sub-field 515 illustrates that user interaction with one ormore displayed sub-fields of interface 500 may reveal further detailsregarding the data illustrated in a respective one of the sub-fields.Such further details may include data related to source code that isreceived as part of the, e.g., stack trace from component C, as shown byexample interface 500.

Such further details may alternatively include a cascading view of thedata in sub-field 515, whereby the cascading view is based upon, e.g.,architectural hierarchy or search criteria. That is, in response to,e.g., a crash, a user command, query, or implementation of a debugger,magnified sub-field 515 may illustrate an upward and/or downward cascadeof constructs for the data in sub-field 515. For example, in response tosuch a command or query to show details regarding threads running oncomponent C, magnified sub-field 515 may further reveal detailsregarding one or more classes, methods, and further threads pertainingto component C.

FIG. 6 shows example processing flow 600 for at least one implementationof active execution tracing visualization. FIG. 6 may be described belowto describe a user's manipulative interaction with example interface 500of FIG. 5, although such implementation is provided as an example onlyand is not intended to be limiting in any manner.

Block 605 may refer to an occurrence that may prompt interface 500 toappear to a user of one of processing devices 105, 110, and 115 (seeFIG. 1), and display data garnered by tracing service 220 (see FIG. 2);that is, display various combinations of data buffered by logging buffer225.

Detect event 607 may constitute an occurrence of block 605. Moreparticularly, detect event 607 may refer to tracing service 220, or anassociated component thereof, detecting an event that may be associatedwith the processing or execution of an application, program, or portionthereof (e.g., component A 205 or component B 210 (see FIG. 2)). Anon-limiting example of such a detected event may be a crash (i.e.,abnormal end) of an application, program, or portion thereof.

Query 608 may alternatively constitute an occurrence at block 605. Moreparticularly, query 608 may refer to tracing service 220 receiving auser command or an automated query from, e.g., a debugger, to inquireabout the processing status of an application, program, or particularcomponent thereof. The aforementioned command and query may be made viainterface 500, although such implementation is not an exclusive example.

Block 610 may refer to, in response to the occurrence detected at block605, interface 500 displaying data pertaining to the processing of anapplication, program, or component thereof. Interface 500, as shown anddescribed in relation to FIG. 5, provides a non-limiting example of suchdisplay.

Decision 615 may refer to a determination by interface 500 of whether auser command or automated query has been received for the display offurther data pertaining to the application, program, or particularcomponent thereof displayed at block 610. Depending on the depth of thedata displayed at block 610, the command or request determined to bereceived at decision 615 may be for myriad of combinations of: e.g., aninstruction, or at least a data representation thereof, for a componentto enter into execution; a corresponding stack trace; a return address;a callback method; the time that an instruction is passed to therespective component; the name of the respective component; aninstruction for the component to exit from execution; etc. Further, thecommand or request determined to be received at decision 615 may seekdetails regarding one or more classes, methods, and further threadspertaining to the data for the application, program, or particularcomponent thereof displayed at block 610.

Negative decision 615 may result in the data for the application,program, or particular component thereof displayed at block 610remaining unchanged, and processing flow 600 returning to block 605.Alternatively negative decision 615 may result in the termination ofprocessing flow 600 for active execution visualization.

Block 620, subsequent to positive decision 615 may result in at leastone of an ascending and descending cascade-ordering of the further datarequested as detected at decision 615. For example, at block 620,interface 500 may cause components that follow and/or precede aspecified component as revealed by a stack trace to be orderedhierarchically or cause an ascending or descending organization ofclasses, methods, and threads, beginning with the requested elementthereof. The organization may be based upon, e.g., architecturalstructure or search criteria. Furthermore, both constructs of suchorganization as well as sub-constructs of such organization may beordered topologically based on their dependencies within a respectivecall stack. These examples of cascade ordering of data are provided asexamples only, and are not intended to be limiting in any manner.

Block 620 may refer to interface 500 displaying the data organized atblock 620 in at least one of ascending and descending order.Non-limiting examples of display implementations for displaying the dataorganized at block 620 include additional hierarchically orderedsub-fields on interface 500 or cascading data fields that hover above afield or sub-field of interface 500 that is activated by a user using acursor.

Subsequent to block 625, processing flow 600 may revert back to decision615.

By the above description, tools, implementations, and interfaces used tocapture, study, and analyze events leading to a point-of-failure duringexecution of a function or at least a portion of an application,program, process, or other assemblage of programmable and executablecode has been provided.

It is to be understood that the computer environment for any of theexamples and implementations described above may include a computingdevice having, for example, one or more processors or processing units,a system memory, and a system bus to couple various system components.

The computing device may include a variety of computer readable media,including both volatile and non-volatile media, removable andnon-removable media. The system memory may include computer readablemedia in the form of volatile memory, such as random access memory(RAM); and/or non-volatile memory, such as read only memory (ROM) orflash RAM. It is appreciated that other types of computer readable mediawhich can store data that is accessible by a computer, such as magneticcassettes or other magnetic storage devices, flash memory cards, CD-ROM,digital versatile disks (DVD) or other optical storage, random accessmemories (RAM), read only memories (ROM), electrically erasableprogrammable read-only memory (EEPROM), and the like, can also beutilized to implement the example computing system and environment.

Reference has been made throughout this specification to “an example,”“alternative examples,”. “at least one example,” “an implementation,” or“an example implementation” meaning that a particular described feature,structure, or characteristic is included in at least one implementationof the present invention. Thus, usage of such phrases may refer to morethan just one implementation. Furthermore, the described features,structures, or characteristics may be combined in any suitable manner inone or more implementations.

One skilled in the relevant art may recognize, however, that theinvention may be practiced without one or more of the specific details,or with other methods, resources, materials, etc. In other instances,well known structures, resources, or operations have not been shown ordescribed in detail merely to avoid obscuring aspects of the invention.

While example implementations and applications of the present inventionhave been illustrated and described, it is to be understood that theinvention is not limited to the precise configuration and resourcesdescribed above. Various modifications, changes, and variations apparentto those skilled in the art may be made in the arrangement, operation,and details of the methods and systems of the present inventiondisclosed herein without departing from the scope of the invention, asboth described above and claimed below.

1. A computer-readable medium having a data structure thereon, the datastructure comprising: a first data field to display a timelinecorresponding to processing of an application; a second data field todisplay data responsive to a data query regarding the processing of theapplication; and a third data field to display data hierarchicallyrelated to the data displayed in the second data field.
 2. Acomputer-readable medium according to claim 1, wherein the datastructure further comprises one or more data fields to display datahierarchically depending from data displayed in a preceding one of thedata fields.
 3. A computer-readable medium according to claim 1, whereinthe data structure further comprises one or more data fields to displaydata from which data displayed in a preceding one of the data fieldsdepends.
 4. A computer-readable medium according to claim 1, wherein thedata displayed in the second data field pertains to at least one frameof a call stack for a function of the application.
 5. Acomputer-readable medium according to claim 1, wherein the datadisplayed in the second data field relates to at least one of a returnaddress and a callback method.
 6. A computer-readable medium accordingto claim 1, wherein the data displayed in the third data field dependsfrom the data displayed in the second data field based on architecturalstructure.
 7. A computer-readable medium according to claim 1, whereinthe data displayed in the third data field hierarchically depends fromthe data displayed in the second data field based on search criteria. 8.A computer-readable medium according to claim 1, wherein the datadisplayed in at least one of the second field and the third field pointsto source code for at least one function call of the application.
 9. Acomputer-readable medium according to claim 8, wherein the datadisplayed in the second data field and the data displayed in the thirddata field are received from a logging buffer corresponding to anapplication tracing service.
 10. A computer-readable medium having oneor more computer-readable instructions that, when executed, cause one ormore processors to: display designated data, from at least one callstack, related to an application; display further data from the at leastone call stack in a cascading manner; and display a time at which datafrom the at least one call stack is buffered.
 11. A computer-readablemedium according to claim 10, wherein the designated data includes adefault search criterion.
 12. A computer-readable medium according toclaim 10, wherein the designated data and the further data are displayedin an order based on a topological sort of dependencies in the at leastone call stack.
 13. A computer-readable medium according to claim 10,wherein the cascading manner is based on a topological sort ofdependencies in the at least one call stack.
 14. A computer-readablemedium according to claim 10, having one or more computer-readableinstructions that, when executed, cause one or more processors tofurther: display a pointer to at least a portion of source code relatingany selected one of the displayed data from the at least one call stack.15. A computer-readable medium according to claim 10, having one or morecomputer-readable instructions that, when executed, cause one or moreprocessors to further: display cascading data, frames from the at leastone call stack, related to another function.
 16. A system, comprising:means for displaying a component of an application; and means fordisplaying further components of the application in a hierarchicalmanner.
 17. A system according to claim 16, further comprising means fordisplaying at least a pointer to source code for a respective one of thedisplayed components of the application.
 18. A system according to claim16, further comprising means for selecting the component.
 19. A systemaccording to claim 16, further comprising means for displaying a timecorresponding to at least one of the displayed components.